| TCPDUMP(1) | General Commands Manual | TCPDUMP(1) |
名前¶
tcpdump - ネットワークのトラフィックをダンプする
書式¶
tcpdump [ -adeflnNOpqRStvxX ] [ -c
count ] [ -F file ]
[ -i interface ] [ -m module ] [ -r
file ]
[ -s snaplen ] [ -T type ] [ -w file
]
[ expression ]
説明¶
tcpdump は真偽値の 条件式 に一致するネットワークインターフェイス上のパケットのヘッダを表示する。
nit か bpf を用いる SunOSの場合: tcpdump を動作させるためには /dev/nit か /dev/bpf* に読み込み権限を持っている必要がある。 dlpi を利用する Solaris の場合: 仮想ネットワークデバイス、たとえば /dev/le といったものに読み込み権限を持っている必要がある。 dlpi を利用する HP-UX の場合: 実行者が root であるか、または root に setuid してインストールされている必要がある。 snoop を用いる IRIX の場合: 実行者が root であるか、または root に setuid してインストールされている必要がある。 Linux の場合: 実行者が root であるか、または root に setuid してインストールされている必要がある。 Ultrix および Digital UNIX の場合: まず、スーパーユーザが pfconfig(8) を用いて無差別透過モード(promicuous-mode)を有効にする必要がある。 その後は一般ユーザが tcpdump を実行可能である。 BSD の場合: /dev/bpf* に対する読み込み権限が必要。
オプション¶
- -a
- ネットワークとブロードキャストアドレスを DNS 名に変換する。
- -c
- count 個のパケットを受信したのちに終了する。
- -d
- コンパイルされたパケットマッチングコードを人間が読める形式で標準出力にダンプし、終了する。
- -dd
- パケットマッチングコードを C 言語の一部として利用可能なかたちでダンプする。
- -ddd
- パケットマッチングコードを 十進数でダンプする(count が先行する)。
- -e
- 各ダンプ行にリンクレベルヘッダを表示する。
- -f
- 「外部の」インターネットアドレスをシンボルではなくて数値で表示する (このオプションは馬鹿な Sun の yp サービスを迂回することを意図している — Sun の yp サービスはローカルではないインターネットアドレスを変換しようとすると 永久に動作が停止してしまうバグがある)。
- -F
- フィルター条件式の指示入力として file を用いる。 この後ろにコマンドラインで条件式による指示が与えられても無視する。
- -i
- interface を監視する。 指示のない場合は tcpdump はシステムのインターフェイスのリストから 最も小さい番号で有効になっているもの(但しループバックは除く)を探し出す。 指示されたインターフェイスが存在しない場合はもっとも近いものが選択される。
- -l
- 標準出力をバッファリングする。データを蓄積しながら監視する場合に有効で
ある。使用例:
``tcpdump -l | tee dat'' or ``tcpdump -l > dat & tail -f dat''. - -n
- アドレス(ホストアドレス、ポート番号など)を名前に変換しない。
- -N
- ホストのドメイン名を表示しない。 つまりこれを使用した場合 tcpdump は``nic.ddn.mil'' と表示するかわりに ``nic'' と表示する。
- -m
- SMI MIB モジュールをファイル module から読み込む。 複数の MIB モジュールを読み込む目的で、 このオプションを複数回使用することも出来る。
- -O
- パケットマッチングコードオプティマイザを停止する。 これはオプティマイザのバグを疑っている場合にのみ有益である。
- -p
- 無差別透過モードを 利用しない。しかしながら、他の理由でインター フェイスが無差別透過モードになってしまうこともあることに注意すること。 このため `-p' オプションは `ether host {loca-lw-addr} or ether broadcast' の省略形としては使用できない。
- -q
- すばやい(というか静かな)出力。限定されたプロトコルの情報しか出力しないので、出力行は短いものとなる。
- -r
- パケットを(-w オプションで作成した)fileから読み込む。 fileとして ``-'' を指定した場合には標準入力が利用される。
- -s
- デフォルトの 68
バイト(SunOS の NIT
では最小は実際には
96 バイト)に代わって
snaplen
バイトをおのおののパケットから取り出し利用する。
IP, ICMP, TCP, UDP については 68
バイトあれば十分だが、ネームサーバや
NFS
の情報には足りないかもしれない(後述)。
snapshot 制限のために後ろが切り捨てられたパケットは出力時に``[|proto]'' の形式で示される。 ここで proto は切り捨ての生じたレベルに対応するプロトコルの名前である。 大きな snapshot を取ろうとするとパケットを処理する時間は増加し、またこちらのほうが重要だが、バッファに溜めることができる量が減少してしまう点に注意すること。 すなわちパケットが失なわれる可能性もある。プロトコルの情報が得られる必要最小限の snaplen とすること。
- -T
- "expression"(条件式) で選択されたパケットに指示された type での翻訳を指示する。現在有効な type は rpc (Remote Procedure Call)、 rtp (Real-Time Applications protocol)、 rtcp (Real-Time Applications control protocol)、 snmp (Simple Network Management Protocol), vat (Visual Audio Tool)、 wb (distributed White Board)。
- -R
- ESP/AH パケットが古い定義(RFC1825 〜 RFC1829)に従っていると仮定する。 このオプションが指定されると、tcpdump は relplay prevention フィールドを表示しない。 ESP/AH の定義にはプロトコルバージョンフィールドがないので、 tcpdump は ESP/AH プロトコルのバージョンを推論することが出来ない。
- -S
- TCP シーケンス番号を相対値ではなくて絶対値で表示する。
- -t
- ダンプ行に時間情報を表示しない。
- -tt
- ダンプ行に表示する時間情報を整形しない。
- -v
- (ちょっとだけ)詳細な出力。IP パケットにおける 生存時間(TTL) やサービスの種類の情報などを表示する。
- -vv
- もっと詳細な出力。NFS応答パケットにおける付加フィールドなどを表示する。
- -vvv
- さらに詳細な出力。 例えば、telnet SB ... SE オプションは全て表示される。 -X オプションも指定されると、telnet オプションは 16 進表示でも表示される。
- -w
- パケットを解析、表示するかわりに生のまま file に書き出す。 このファイルはあとで -r オプションを用いれば表示することができる。 file として `-' を指示すると標準出力を用いる。
- -x
- (リンクレベルヘッダを除く)すべてのパケットを 16 進で表示する。パケット全体と snaplen バイトの小さい方だけを表示する。
- -X
- 16 進表示されるときに、 ASCII 文字も表示する。 従って、 -x オプションもセットされると、パケットは 16 進と ASCII 文字の両方で表示される。 これは新しいプロトコルを解析するときに非常に便利である。 -x オプションが設定されていなくても、 パケットの部分によっては 16 進と ASCII 文字の両方で表示されることもある。
expressionは一つ以上の primitive(要素) から成る。要素は一つ以上の修飾子を先行する一個の id (名前でも番号でもよい)である。修飾子には三つの種類がある:
- type
- 修飾子は id名または id 番号が指すものの種類を示す。利用可能なものは host, net, port である。例: `host foo'、`net 128.3'、`port 20'。 type 修飾子が無い場合は、 host が指示されているものとみなす。
- dir
- 修飾子は id に向けて、または id へ、のどちらかあるいは両方の通信方向を特定する。方向として指示できるのは src, dst, src or dst, src and dst である。例、 `src foo'、`dst net 128.3'、`src or dst port ftp-data'。 dir 修飾子が指定されない場合は src or dst が指示されているものとみなす。`null' リンク層(すなわち slip のよう なポイントツーポイントプロトコル)においては、方向を指定する修飾子として inbound と outbound も利用可能である。
- proto
- 修飾子は一致する特定のプロトコルに制限する。利用可能なプロトコルは以下の通り: ether, fddi, mopdl, ip, ip6, arp, rarp, decnet, lat, sca, moprc, mopdl, icmp, icmp6, tcp, udp。 例: `ether src foor'、`arp net 128.3'、`tcp port 21'。 proto 修飾子が指示されない場合は type と矛盾しない範囲で全てのプロトコ ルが指示されているものとみなす。 例: `src foo' は `(ip or arp or rarp) src foo' (このような書き方は文法あやまりだが)を意味し、 `net bar' は `(ip or arp or rarp) net bar' を意味し、 また `port 53' は `(tcp or udp) port 53' を意味する。
[`fddi'は実際には `ether' の別名である;解析時に``特定のネットワー クインターフェイスが利用するデータリンク層''として扱われる。FDDI ヘッ ダーはイーサネット的なソースおよびディスティネーションアドレスを含み、ま たイーサネット的なパケットタイプも含むので、これらの FDDI フィールドを イーサネットの同類として選別できる。FDDI ヘッダにはその他のフィールド も含まれるが、これについてはフィルタの条件式で明示的に指示することはで きない。]
上記に加えて、特別な`要素'を示すキーワードがある。 gateway, broadcast, less, greater とarithmtic expression(数値による条件式)である。これらについてはこのあとで記述する。
もっと複雑なフィルタ条件式は and, or, not と各要素の組合せで表現できる。 例:`host foo and not port ftp and not port ftp-data'。 明示的な修飾子は省略してタイプ数を減らすことができる。 例:`tcp dst port ftp or ftp-data or domain' は `tcp dst prot ftp or tcp dst port ftp-data or tcp dst prot domain'と全く同じ意味である。
許容される要素の組み合わせは以下の通り。
- dst host host
- パケットの IPv4/v6 ディスティネーションフィールドが host であるとき真。アドレスでも名前でもよい
- src host host
- パケットの IPv4/v6 ソースフィールドが host であるとき真。
- host host
- パケットの IPv4/v6
ソースまたは IP/v4/v6
ディスティネーションフィールドが
host であるとき真。
上記の各 host
を示す条件式には
ip、arp、rarp、ip6
のいずれかを付加してもよい。
ip host host
は下記と同じ。
ether proto \ip and host host
もし host の名前が複数の IP アドレスを持つ時はそれぞれのアドレスに一致する。 - ether dst ehost
- イーサネットディスティネーションアドレスが ehost であるときに真。 ehost は /etc/ethers か数値である(数値のフォーマットについては ethers(3N) を参照のこと)。
- ether src ehost
- イーサネットソースアドレスが ehost であるときに真。
- ether host ehost
- イーサネットソースアドレスかディスティネーションアドレスが ehost であるときに真。
- gateway host
- パケットが host
をゲートウェイとしているときに真。
すなわち、イーサネットソース/ディスティネーションアドレスは
host であるが、 IP
ソース/ディスティネーションアドレスは
host
ではないときのこと。
host
は名前であり、また
/etc/hosts と /etc/ethers
の両方に記載されていなければならない
(この条件式は host / ehost
それぞれを名前か番号で記述する
ether host ehost and not host host
と同等である)。 この文法は今のところ IPv6 を有効にした設定では正しく動作しない。 - dst net net
- パケットの IPv4/v6 ディスティネーションアドレスが net ネットワークを 含んでいるときに真。net は/etc/networks に記載される名前かネット ワーク番号である( networks(4) を参照)。
- src net net
- パケットの IPv4/v6 ソースアドレスが net ネットワークのものであるときに真。
- net net
- パケットの IPv4/v6 ソース/ディスティネーションアドレスが net ネットワークであるときに真。
- net net mask mask
- IP アドレスが netmask でマスクして net に一致するときに真。src か dst で修飾してもよい。 この文法は net が IPv6 のときには不正であることに注意。
- net net/len
- IPv4/v6 アドレスが len ビットのnetmask でマスクして net に一致するときに真。src か dst で修飾してもよい。
- dst port port
- パケットが ip/tcp か ip/udp か ipv6/tcp か ipv6/udp である場合で、 行き先の port 番号が port であるときに真。 Port は番号の数値か /etc/services による名前を利用できる( tcp(4P) と udp(4P) を参照のこと)。名前が利用されている場合は port 番号と protocol の両方で照合される。 番号か多重に定義されている名前が利用されている場合は port 番号だけが照合される (例: dst port 513 は tcp/login と udp/who の両方の通信を表示するし、 port domain は tcp/domain と udp/domain の両方を表示する)。
- src port port
- パケットが port 番号のポートをソースにしているとき真。
- port port
- パケットのソースかディスティネーションポートが
port であるとき真。
この port
を指定する条件式は
tcp と udp
のキーワードを付加してもよい:
tcp src port port
は port をソースとする tcp のパケットのみに一致する。 - less length
- パケットが length
以下のときに真。
これは下記と同じ:
len <= length.
- greater length
- パケットが length
以上のときに真。
これは下記と同じ:
len >= length.
- ip proto protocol
- パケットが protocol 型のプロトコルの IP パケット( ip(4P) を参照)のものであるとき真。 protocol として利用できるのは数値と icmp、 igrp、udp、nd、tcp である。tcp、udp、 icmp はキーワードでもあるので、バックスラッシュ(\)でキーワード として解釈されるのを回避する必要がある。C-Shell では \\ を使う。 この要素はプロトコルヘッダチェインを追跡しないことに注意。
- ip6 proto protocol
- パケットがprotocol型の IPv6 パケットであるときに真。 この要素はプロトコルヘッダチェインを追跡しないことに注意。
- ip6 protochain protocol
- パケットが IPv6
パケットであり、
そのプロトコルヘッダチェインの中にprotocol型のプロトコルヘッダがある場合に真。
例えば、
は プロトコルヘッダチェインに TCP プロトコルを持つ IPv6 パケットに一致する。 パケットには、例えば認証ヘッダ、ルーティングヘッダ、 hop-by-hopヘッダなどがIPv6 ヘッダと TCP ヘッダの間に含まれるかもしれない。 この要素が作り出す BPF コードは複雑で、 tcpdumpの BPF 最適化コードで最適化できない。 そのため、少し遅いかもしれない。 - ip protochain protocol
- ip6 protochain protocol と同様だが、これは IPv4 のためのものである。
- ether broadcast
- パケットがイーサネットのブロードキャストであるとき真。ether はなくてもよい。
- ip broadcast
- パケットが IP ブロードキャストパケットであるとき真。これは全て 0 と 全て 1 の両方のブロードキャスト形式に対応し、さらにサブネットマスクにも対応している。
- ether multicast
- パケットがイーサネットのマルチキャストであるとき真。ether はなくて もよい。これは `ether[0] & 1 != 0'の省略記法である。
- ip multicast
- パケットが IP のマルチキャストであるとき真。
- ip6 multicast
- パケットが IPv6 マルチキャストパケットであるとき真。
- ether proto protocol
- パケットが ether の protocol 型のものであるとき真。 protocol には番号か ip、ip6、arp、rarp の名前が利 用可能。これらの識別子はキーワードでもあるので、バックスラッシュ(\)で キーワードとして解釈されるのを回避する必要がある。 [ FDDI (たとえば `fddi protocol arp')の場合、プロトコルの識別方法は 802.2 Logical Link Control (LLC) ヘッダーによる。それは通常は FDDI ヘッダーの先頭に置かれている。tcpdump は プロトコル識別子で フィルターする場合に、全ての FDDI パケットは LLC ヘッダーを持っていて、 その LLC ヘッダーは SNAP と呼ばれる形式になっているものとみなす。 ]
- decnet src host
- DECNET においてソースアドレスが``10.123''のようなアドレスや DECNETのホ ストネームの形式で指示される host と一致するとき真。[DECNETのホストネーム形式は DECNETに接続された ultrix システムにおいてのみ利用可能である。]
- decnet dst host
- DECNETにおいてディスティネーションアドレスが host に一致するとき真。
- decnet host host
- DECNETにおいて、ソースまたはディスティネーションアドレスが host に一致するときに真。
- ip, ip6, arp, rarp, decnet
- 下記において:
ether proto p
p をそのいずれかのプロトコルとするのと同等である。 - lat, moprc, mopdl
- 下記において:
ether proto p
p をそのいずれかのプロトコルとするのと同等である。 tcpdump はこれらのプロトコルの解析方法は正確には知らない点に注意 すること。 - tcp, udp, icmp
- 下記において:
ip proto pip6 proto p
p をそのいずれかのプロトコルとするのと同等である。 - expr relop expr
- 関係式が成り立てば真。relop(演算子)は
>、<、>=、<=、=、!=
のいず
れか一つであり、expr(表現)
は整定数による数値表現
(表現方法は標準 的な
C
の文法にしたがう)、標準的な二項演算子[+、-、*、/、&、|]、長さ演算子、パ
ケットデータアクセス演算子のいずれか。パケット内のデータに対して適用するにはこのように記述する:
proto [ expr : size ]
proto は ether、fddi、ip、arp、rarp、tcp、udp、icmp、ip6 のいずれかで 操作対象のプロトコル層を指示する。 tcp, udp とその他の上位プロトコル層は IPv4 でのみ利用でき、 IPv6では利用できないことに注意。(これは将来修正されるだろう) 指示されたプロトコル層についてのバイトオフセットは expr で指定する。 size を指示する場合は注目するフィールドでのバイト数で指示するが、 それは one、two また four のいずれかを用いる。指示のない場合は one で あるとみなす。長さ演算子はキーワード len で示され、パケット長を与える。 たとえば、`ether[0] & 1 != 0'という条件式はすべてのマルチキャスト による通信をとらえる。`ip[0] & 0xf != 5' という条件式はすべてのオ プション付きの IP パケットをとらえる。`ip[6:2] & 0x1fff = 0'はフラ グメント化されていないデータグラムか 0 番の(最初の)フラグメントだけを表示する。 なお、この条件は tcp と udp への適用を暗示している。さら に tcp[0] は TCP ヘッダ の最初のバイトを意味するが、フラ グメントの先頭のバイトではありえない。
要素を複合させて用いる場合:
- 括弧でグループ分けする要素と演算子(括弧はシェルにとっても特別な意味を持つのでたぶんエスケープしなければならないだろう)。
- 否定 (`!' or `not').
- 結合 (`&&' or `and').
- 択一 (`||' or `or').
否定はもっとも高い優先度をもつ。択一と結合は同等の優先度を持ち、 左から右へ評価される。 結合は併記するだけでなく明示的な and トークンが必要なことに注意すること。
キーワードなしで識別子があらわれた場合、直前にあらわれたキーワードを
伴っているとみなされる。
たとえば、
not host vs and ace
は
not host vs and host ace
の省略であり、これは
not ( host vs or ace )
とは違う。
tcpdump に渡す条件式は都合のよいように、単一としても複数としてもよい。 一般にシェルのメタキャラクタを含むような条件式の場合は単一のクオートした引数として渡すのがよい。 複数の引数は評価の直前に空白で結合される。
例¶
ホスト sundown にかかわる全ての入出力パケットを表示する:
tcpdump host sundown
ホスト helios と hot あるいは ace との通信を表示する:
tcpdump host helios and \( hot or ace \)
ホスト ace と helios を除く全てのホストとのIPパケットを表示する:
tcpdump ip host ace and not helios
ローカルネットのホスト群とネットワーク Berkeley のホスト群との通信を表示する:
tcpdump net ucb-ether
インターネットへのゲートウェイの snup を通過する全ての ftp 通信を表示する(条件式はシェルが括弧を(誤って)解釈するのを避けるためにクオートされている点に注意せよ):
tcpdump 'gateway snup and (port ftp or ftp-data)'
ローカルホストへの入出力の通信を除外して表示する(他のネットワークへのゲートウェイであるとして、ローカルネットワークを除外する例):
tcpdump ip and not net localnet
ローカルホスト以外が関わる TCP 通信の TCP スタートとエンドのパケット(SYN と FIN のパケット)を表示する:
tcpdump 'tcp[13] & 3 != 0 and not src and dst net localnet'
ゲートウェイ snup を通過する 576 バイト以上の IP パケットを表示する:
tcpdump 'gateway snup and ip[2:2] > 576'
イーサネットのブロードキャストまたはマルチキャストを 必要としない IP のブロードキャストまたはマルチキャストを表示する:
tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'
echo 要求/応答(つまり ping のパケット)以外のすべての ICMP パケットを表示する:
tcpdump 'icmp[0] != 8 and icmp[0] != 0"
出力形式¶
tcpdump の出力はプロトコルに依存する。下記は大部分の様式の簡単な解説と例である。
リンクレベルヘッダ
`-e' オプションが指示されている場合、リンクレベルヘッダが表示される。 イーサネットではソースおよびディスティネーションのアドレスとパケット長が表示される。
FDDI のネットワークにおいては '-e' オプションにより tcpdump は、ソ ースおよびディスティネーションのアドレスとパケット長からなるフレーム制御フィールドを表示する。(フレーム制御フィールドはパケットの残りの部分の解釈 の制御をおこなう)。(IP データグラムを含むような)通常のパケットは優先度 0 から 7 を持つ`async' パケットである;たとえば `async 4'。この ようなパケットは 802.2 LLC を含むとみなされる。LLCヘッダはそれが ISO データグラムやいわゆる SNAP パケット でない ならば、表示される。
(注:以下の記述は RFC-1144 による SLIP 圧縮アルゴリズムを理解しているものと みなして記述してある)。
SLIP 接続では、方向指示(``I''が入力、``O''が出力)、パケットタイプと圧縮情報が表示される。 最初にパケットタイプが表示される。 タイプには ip、utcp、ctcp の三種類がある。 ip パケットについてこれ以上のリンク情報は表示されない。 TCPパケットは接続識別子が次に表示される。 パケットが圧縮されている場合はその符号化されたヘッダが表示される。 *S+n、*SA+n と表示される特別な状態もある。ここで n はシーケンス番号(またはシーケンス番号と ack)が何回変更されたかを示す。 特別な場合でなければ、ゼロかまたは変更の回数が出力される。 変更は U(urgent pointer)、W(windows)、A(ack)、S(sequence number)、I(packet ID)に差分(+n か -n)または新しい値(=n)の組合せで示される。 最後にパケットのデータすべてと圧縮されたヘッダの長さが表示される。
この例は明示された接続識別子をもつ出力される圧縮TCPパケットを示す。 ack は 6回更新され、シーケンス番号は 49であり パケットの IDは 6である; 3バイトのデータと6バイトの圧縮ヘッダを持つ
O ctcp * A+6 S+49 I+6 3 (6)
ARP/RARP パケット
arp/rarp 出力は要求のタイプとその引数を表示する。フォーマットそれ自体 が自身の内容の説明となる。この短い例はホスト rtsg から csam への `rlogin' の開始時のものである。
arp who-has csam tell rtsg arp reply csam is-at CSAM
この例は tcpdump -n で実行するとこのように簡略化される:
arp who-has 128.3.254.6 tell 128.3.254.68 arp reply 128.3.254.6 is-at 02:07:01:00:01:c4
Tcpdump -e で実行すると最初のパケットがブロードキャストで二番目は point-to-point であることが見てとれる:
RTSG Broadcast 0806 64: arp who-has csam tell rtsg CSAM RTSG 0806 64: arp reply csam is-at CSAM
TCP パケット
(注: 以下は RFC-793 で記述される TCPプロトコルを理解しているものと みなして記述してある。もしこのプロトコルに通じていないようなら、この記 述だけでなく、tcpdump そのものも役に立たないだろうが。)
一般的なフォーマットは下記の通り:
src > dst: flags data-seqno ack window urgent options
src、dst と flags はかならず表示される。他のフィールドはパケットの TCP プロトコルヘッダに依存するので必要な場合のみ表示される。
これはホスト rtsg から csam へのrlogin の開始時の一部。
rtsg.1023 > csam.login: S 768512:768512(0) win 4096 <mss 1024> csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096 <mss 1024> rtsg.1023 > csam.login: . ack 1 win 4096 rtsg.1023 > csam.login: P 1:2(1) ack 1 win 4096 csam.login > rtsg.1023: . ack 2 win 4096 rtsg.1023 > csam.login: P 2:21(19) ack 1 win 4096 csam.login > rtsg.1023: P 1:2(1) ack 21 win 4077 csam.login > rtsg.1023: P 2:3(1) ack 21 win 4077 urg 1 csam.login > rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1
これに対して、csam は rtsg の SYN に対する ack を含む他は同等の内容のパケットを返している。 そこで、rtsg は csam の SYN に ack 応答を返す。`.' はフラグがセットされていないことを示す。 このパケットにはデータが含まれないので、シーケンス番号もない。ack 応答のシーケンス番号は小さな整数 1 である点に注意すること。 最初に tcp の「会話」を見いだすと、tcpdump はそのパケットのシー ケンス番号を出力する。その会話のパケットからは、そのシーケンス番号と 初期化されたシーケンス番号との差異が表示される。 これは最初以外のシーケンス番号はその会話のデータグラムにおける相対的な バイト位置として解釈できることを意味する (各データグラムは 1 から始ま る)。 '-S' オプションはこの機能を無視して、本来のシーケンス番号を出力する。
6 行目で rtsg は scam へ 19 バイト(rtsg から csam の方向へ、2 バイト目 から 20 バイト目まで) のデータを送る。このパケットには PUSH フラグが設定されている。7 行目で、 csam は rtsg が送信したデータを受信した、と言っているが、これには 21 バイト目は含まれない。csam の受信 window が 19 バイト小さくなっていることか ら、このデータはソケットバッファに留まっていると推測される。csam はま た 1バイトのデータを rtsg に送信する。8 行目と 9 行目とで csam は urgent および pushed 付きのパケット 2バイト をrtsg へ送信している。
もし、snapshot が小さすぎて tcpdump が TCP ヘッダの全てを捉えられなかった場合は、できるだけ の解釈をして、その残りには解釈不能だったものがあることを示すために ``[|tcp]''と表示する。ヘッダに意味不明なオプション(たとえば、小 さすぎたり、ヘッダよりも長かったりする length とか)が設定されていた場 合は、tcpdump は ``[bad opt]''と表示し、それ以上のオプション解析 を中止する(それがどこから始められるかわからないので)。 ヘッダ長がオプションを送信したことを示しているのに、 IP データグラム長はそこにオプションを含められないことを示す場合は tcpdump は ``[bad hdr length]''と表示する。
UDP パケット
UDP はこの rwho のパケットで説明する:
actinide.who > broadcast.who: udp 84
いくつのかの UDP サービスに関しては(そのソースまたはディスネーション のポート番号より)解釈することができ、より上位の層におけるプロトコル 情報を表示する。特にドメインネームサービス要求(RFC-1034/1035)や NFS についての Sun RPC (RFC-1050)について出力される。
UDP ネームサービス要求
(注:以下は RFC-1035 で記述される ドメインネームサービスプロトコルを 理解しているものとみなして記述している。 もしこのプロトコルに通じていないようなら、以下の記述はちんぷんかんぷんかもしれない。)
ネームサーバの要求は、
src > dst: id op? flags qtype qclass name (len)
h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)
のような形式である。例外的なものを検出した場合、追加のフィールドを[ ] で囲んで表示するだろ う:もし問合せ(query)に回答、ネームサーバ、権威セクションが含まれる場合、 ancount, nscount, arcount はそれぞれn をカウント数として、 `[na]'、`[nn]' か `[nau]' のように表示される。 もし、第二および第三バイトにいくつかの応答bitが設定されている(AA、RA か または rcode)場合か、`must be zero' ビットが設定されている場合は `[b2&3=x]'と表示する。ここで x はヘッダの第二および第三バイトの 16 進表現である。
UDP ネームサーバ応答
ネームサーバからの応答は、
src > dst: id op rcode flags a/n/au type class data (len) helios.domain > h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273) helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97)のような形式である。
次の例は helios はドメインが存在しない、という response code (NXDomain) で回答はなし、ネームサーバは一個、権威レコードもなし、という返答をしている。 `*' は authoritative answer ビットが設定されていることを示す。 回答がないので、 type とクラスおよびデータは表示されない。
ほかのフラグは`-'(RA(再帰可)が設定されていない)、`|'TC(まるめら れたメッセージ)が設定されている。`question' セクションが一つでない場合 には、`[nq]'と出力する。
ネームサーバの応答はデフォルトの snaplen である 68 バイトよりも大きくなりがちなので、 そのパケットを表示するのに十分なだけの情報を捉えきれないことがある。 ネームサービスの通信を厳密に解析したいときは、-s フラグを利用して snaplen を拡張するべきである。 `-s 128'くらいが妥当であろう。
SMB/CIFS 展開
tcpdump は UDP/137, UDP/138, TCP/139 に対する比較的大規模な SMB/CIFS/NBT デコード機能を持つ。 IPX と NetBEUI SMB をデコードする要素もある。
デフォルトでは比較的小規模なデコードが行われ、 -v オプションを用いると遥かに詳細なデコードが行われる。 -v オプション付きの場合、ひとつの SMB パケットが 1 画面以上の情報を出す場合もあるので、 本当に必要な場合のみ -v オプションをつけること。
UNICODE 文字列を含む SMB セッションをデコードする場合は、 環境変数 USE_UNICODE に 1 をセットしたほうがいいかもしれない。 UNICODE 文字列を自動検出するパッチは歓迎する。
SMB パケットの形式や all teフィールドが何を意味するかの情報は、 www.cifs.org か samba.org ミラーサイトの pub/samba/specs/ ディレクトリを参照のこと。 SMB パッチは Andrew Tridgell (tridge@samba.org) が書いた。
NFS 要求と回答
Sun NFS(Network File System)の要求と応答は次のように出力される:
src.xid > dst.nfs: len op args src.nfs > dst.xid: reply stat len op results sushi.6709 > wrl.nfs: 112 readlink fh 21,24/10.73165 wrl.nfs > sushi.6709: reply ok 40 readlink "../var" sushi.201b > wrl.nfs: 144 lookup fh 9,74/4096.6878 "xcolors" wrl.nfs > sushi.201b: reply ok 128 lookup fh 9,74/4134.3150
三行目では sushi は wrl に対し ディレクトリファイル 9,74/4096.8678 から `xcolors' を探し出すように要求している。 出力されるデータは操作の種類によって依存していることに注意すること。 この出力形式は NFS プロトコル仕様とともに読んだ場合に自己説明になるよう意図された形式である。
-v(verbose) フラグが与えられている場合、追加の情報も出力される。例:
sushi.1372a > wrl.nfs: 148 read fh 21,11/12.195 8192 bytes @ 24576 wrl.nfs > sushi.1372a: reply ok 1472 read REG 100664 ids 417/0 sz 29388
-v フラグが複数与えられると(-vvのこと)もっと詳細な情報が出力される。
NFS の要求はとても大きいので、snaplen を増加しないと十分な情報が表示で きないかもしれないことに注意すること。 NFS の通信を監視する場合は `-s 192' を試してみるとよい。
NFSの返答パケットは RPC操作によって識別することができない。しかしなが ら、tcpdump は ``最近の''要求を覚えておいて、返答がそのトランザ クション IDに一致するか調べる。応答が対応する要求の近くに通信されていない場合はきちんと解析できないかもしれない。
AFS 要求と応答
Transarc AFS (Andrew File System) 要求と応答は以下のように表示される。
src.sport > dst.dport: rx packet-type src.sport > dst.dport: rx packet-type service call call-name args src.sport > dst.dport: rx packet-type service reply call-name args elvis.7001 > pike.afsfs: rx data fs call rename old fid 536876964/1/1 ".newsrc.new" new fid 536876964/1/1 ".newsrc" pike.afsfs > elvis.7001: rx data fs reply rename
一般に、全ての AFS RPC は少なくとも RPC 呼び出し名はデコードされる。 ほとんどの AFC RPC は少なくともいくつかの引数はデコードされる (一般に `興味深い' 引数のみがデコードされる)。
表示フォーマットは自己説明的なものを目指しているが、 AFS と RX の動作に詳しくない人々にとってはおそらく便利ではないだろう。
-v (詳細) オプションが 2 回指定されると、追加情報が表示される。 これは RX 呼び出し ID、呼び出し番号、シーケンス番号、シリアル番号、RX パケットフラグなどである。
さらに -v オプションが指定されると、セキュリティインデックスとサービス ID が表示される。
中断パケットのエラーコードも表示される。 但し、Ubik ビーコンパケットは例外である。 (なぜなら、Ubik プロトコルにおける中断パケットは賛成票を意味するからである)。
AFS 要求は非常に大きく、 多くの引数はsnaplenを増やさないとおそらく表示されないことに注意すること。 AFS 通信を監視する場合は `-s 256' を試してみるとよい。
AFS 応答パケットは明示的に RPC 操作を識別しない。 代わりに、tcpdumpは``最近の''要求を覚えていて、 それを呼び出し番号とサービス ID を用いて応答と照合させる。 もし応答が対応する要求と結び付けられなかった場合、そのパケットはパーズできない。
KIP Appletalk (UDP 内 DDP)
UDP データグラム内に格納されたアップルトークの DDP パケットは取り出されて、 DDP パケットとして表示される(すなわちすべての UDP ヘッダ情報は捨てられる)。 /etc/atalk.names ファイルが アップルトークネットとノード番号を名前に変換するのに利用される。 ファイルの形式は下記の通り。
番号 名前 1.254 ether 16.1 icsd-net 1.254.110 ace
アップルトークのアドレスは次の形式で表示される。
net.host.port 144.1.209.2 > icsd-net.112.220 office.2 > icsd-net.112.220 jssmag.149.235 > icsd-net.2
NBP(名前解決プロトコル)と ATP(アップルトークトランザクションプロトコル)パケットについては、その内容も解析される。 その他のプロトコルはプロトコル名(名前がわからなければ番号)とパケットのサイズが表示されるだけである。
NBP パケット は次の例のように表示される:
icsd-net.112.220 > jssmag.2: nbp-lkup 190: "=:LaserWriter@*" jssmag.209.2 > icsd-net.112.220: nbp-reply 190: "RM1140:LaserWriter@*" 250 techpit.2 > icsd-net.112.220: nbp-reply 190: "techpit:LaserWriter@*" 186
ATP パケット は次のように表示される:
jssmag.209.165 > helios.132: atp-req 12266<0-7> 0xae030001 helios.132 > jssmag.209.165: atp-resp 12266:0 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:1 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:2 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:4 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:6 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp*12266:7 (512) 0xae040000 jssmag.209.165 > helios.132: atp-req 12266<3,5> 0xae030001 helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000 helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000 jssmag.209.165 > helios.132: atp-rel 12266<0-7> 0xae030001 jssmag.209.133 > helios.132: atp-req* 12267<0-7> 0xae030002
helios は八個の 512 バイトのパケットを返答している。トランザクションid に続く `:数字' 表現はトランザクションにおけるパケットのシーケンス番号で、カッコに囲まれた数字は atp ヘッダを除いたパケットのデータ量である。パケット 7 番の `*' は EOM ビットが設定されていることを示す。
jssmag.209 はパケット 3 番とパケット 5 番の再送を要求している。helios はそれらを再送し、jssmag はトランザクションを終了する。そして、 jssmag.209 は次の要求を開始する。要求の `*' は XO (`一回だけ')は設定 されていない ことを示す。
IP フラグメント化(fragmentation)
インターネットデータグラムのフラグメント化されたものは次のように表示する。
(frag id:size@offset+) (frag id:size@offset)
id はフラグメントの id 。size はフラグメントの IP ヘッダを除くサイズ(バイトで)。offset はフラグメントのもともとのデータグラム内でのオフセット(バイトで)。
フラグメントの情報はフラグメント毎に表示される。最初のフラグメントには 上位プロトコルのヘッダを含み、フラグメント情報はプロトコル情報に続いて 表示される。二番目以降のフラグメントには上位プロトコルの情報を含まない ので、フラグメント情報はソースおよびディスティネーションアドレスに続いて表示される。 以下の例は CSNET で接続された arizona.edu から lbl-rtsg.arpa への ftp 接続の一部を示すが、これには 576 バイトのデータグラムはあらわれていない:
arizona.ftp-data > rtsg.1170: . 1024:1332(308) ack 1 win 4096 (frag 595a:328@0+) arizona > rtsg: (frag 595a:204@328) rtsg.1170 > arizona.ftp-data: . ack 1536 win 2560
フラグメント化禁止フラグ の設定されたパケットの場合、行末に (DF)と表示する。
時間表示
デフォルトでは全ての出力行の先頭にタイムスタンプがつく。タイムスタンプは現在の時刻を次の形式で表示し、
hh:mm:ss.frac
関連項目¶
traffic(1C), nit(4P), bpf(4), pcap(3)
著者¶
原著者は:
Van Jacobson, Craig Leres and Steven McCanne, all of the Lawrence Berkeley National Laboratory, University of California, Berkeley, CA.
最新版は tcpdump.org によって管理されている。
IPv6/IPsec のサポートは WIDE/KAME プロジェクトによって追加された。 このプログラムは Eric Young の SSLeay ライブラリを特定の設定の元に使用している。
バグ¶
問題点、バグ、質問、拡張のお願いなどは、以下のアドレスに送ってほしい。
ソースコードの寄贈などは以下のアドレスへ送ってほしい。
NIT は外へ出ていく通信は見ることができない。BPF はそれが可能である。後者の利用を推奨する。
用途によっては、IPフラグメントを再構築したり、上位プロトコルの長さを計算するくらいのことは必要となるだろう。
ネームサーバの逆引き要求は正確に表示できない。(空の)質問はむしろ回答の 中に含まれる要求として表示される。逆引き要求にはバグがふくまれていて、 それを修正するのは tcpdump ではなくてネームサービスの方であるべきと考 えている人もいる。
アップルの EtherTalk の DDP パケットは KIP DDP パケットのように容易に dump できるはずだが、行なわない。たとえ ethertalk を扱おうという気になっ ても(なってないが)、LBLが ネットワーク上のethertalk へのアクセスを許さ ないので、コードのテストができないのだ。
夏時間に切り替わるときにパケットトレースを行なっていると時間がずれてし まう(時間の変更は無視される)。
FDDI ヘッダに対するフィルタの条件式はすべての FDDI パケットがイーサネット のパケットをカプセル化しているものとみなして適用される。 これは、IP,ARP と DECNET PhaseIV については正しく動作するが、 ISO CLNS のようなプロトコルではうまくいかないだろう。 それゆえにフィルターは条件式に一致しないようなパケットをあやまって あつかってしまうかもしれない。
ip6 proto はヘッダチェインを追跡するべきだが、今のところそうはなっていない。 tcp や udp もヘッダチェインを追跡するべきである。
tcp[0]のようなトランスポート層ヘッダに対する算術表現は、 IPv6 パケットに対してはうまく働かない。 IPv4 パケットに対してのみ働く。
| 30 June 1997 |